fix(html): stray line numbers, and two refusals that described the old editor - #879

🤖 Generated with Claude Code

Two things found by opening the wasm example and using it.

Stray line numbers in a .txt

Deleting across several lines left one line number behind per line — 9 lines
deleted down to 7 left 8 numbers.

removeText did textNr.removeChild(textNr.lastChild). The renderer writes
the gutter formatted, so there is a whitespace text node after the last cell:
lastChild was that whitespace, and the cell survived. lastElementChild is
what reaches a cell.

The comment above getPosition already warns about exactly this for the lines
— "formatted output puts a whitespace text node between them, and counting or
indexing those as lines is off by as much as a factor of two" — and nobody
carried it across to the gutter, which is written the same way. It now says so.

A check on the page drives a three-line delete and asserts the two counts move
together, and that undo brings both back.

Two refusals describing the editor as it was

• Code 1 said "new line not supported by this document". Enter has been
  taken since feat(html): a text editor that owns the edit #875; the code now marks only a soft line break.
• Code 8 said "an edit has to lie inside one run of text". That was true
  before feat(html): a text editor that owns the edit #875 and reads as though editing across runs does not work — which is
  exactly how it was reported to me. It now marks a range reaching over a
  picture or a table.

Codes are untouched, so nothing a host maps changes. The refusal table in
editing.md now also says why a range over a picture is refused:
replaceRange takes runs and whole paragraphs away, so anything else caught
between the ends would survive while the text around it went.

Reference output

resources/editing.js and resources/text.js change, so this needs a pin
advance once it lands.